Date: Tue, 1 Jun 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #152 

To: packet-radio 


Packet-Radio Digest Tue, 1 Jun 93 Volume 93 : Issue 152 


Today's Topics: 
AMPRnet 
k2cc:BitBucket (no!!) 
MiniSport Hacker - Vol 13 
Need a data radio recommendation. (9600 min, 56K ??) 
NOS 
Packet Radio 
PBBS setup for Unix... 
Welcome to rec.radio.info! 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 1 Jun 1993 05:40:36 -0500 

From: usc!cs.utexas.edu!not-for-mail@network.UCSD.EDU 
Subject: AMPRnet 

To: packet-radio@ucsd.edu 


Hi all, 


I want to know some info about TCP/IP across AX.25. I want to use NET.EXE 
by KA9Q. The problem is I don't know who assigns IP adresses in 44 net. 

I think there is probably something like "Country Coordinator" and 
"Central Coordinator" for this (or am I wrong?), but I'm not sure if 
Czech Republic has someone responsible for this. 


73, (very soon will be) OK1XPV 


Petr Vyhnak 


P.S.: I would prefer replies via E-mail to VYHNAK@CSPGUK11.BITNET, because 
reading NetNews is very complicated from here. thanks. 


Date: Mon, 31 May 1993 14:47:31 GMT 

From: usc!howland.reston.ans.net!xlink.net!sol.ctr.columbia.edu!news.kei.com!ub! 
clarkson! rob.n2qcn.clarkson.edu! rob@network.UCSD.EDU 

Subject: k2cc:BitBucket (no!!) 

To: packet-radio@ucsd.edu 


> The NOS Mailbox throws all messages to k2cc or k2cc@k2cc into the bit bucket 
they are forwarded to n2nvf (virg@cheetah.ece.clarkson.edu) who is 

adding accounts for us durring the summer... this is a student station 

and there arn't meny students here in the summer.. it takes a day for 

her to read her mail as she don't have direct access. 


rob@sun.soe.clarkson.edu 


Rob Logan AMA so === - |----- ARRL n2qcn@k2cc-2.ny.usa.na 
Clarkson ERC IRCHA *>=====[_]L) EAA AixrBorn 

Potsdam, NY 13699 PRA -'-*- PADI USSA 

work: 315-268-2292 fax: 315-268-6570 home: 315-265-2391 


Date: 31 May 93 00:06:37 GMT 

From: olivea!isc-br!tau-ceti! comtch! opus-ovh! bmork@uunet.uu.net 
Subject: MiniSport Hacker - Vol 13 

To: packet-radio@ucsd.edu 


MiniSport Laptop Hacker - Vol 13, 29 Apr 1993 
Copyright(C) 1993 by Brian Mork. 


>>> ADMIN 

No, I'm not superstitious, but the number of this MLH edition did pass my 
mind. The last two weeks, my ZL-2 has been out of commission. Almost si- 
multaneously, I received a letter from n7ftm (Bill) that his is having the 
same trouble. I've spent the last few nights tearing mine apart. Bad for 
me; good for you! I've got more specs on how the power supply works in 
the next edition of MLH. 


In addition, I've been digesting volumes of documentation on Internet and 
Waffle, a BBS program meant to host users and process Internet E-mail and 
Usenet topical forums. I now have a node running on my own computer. See 


the new (and let's hope stable) address below. 


Two people have sent me messages via USMail because something about the 
packet link wasn't getting messages through. Each edition, I try to con- 
firm in the ADMIN section who all I've heard from. If I don't mention 
your callsign here, I didn't get your message. This round I've heard from 
N9ADS, NOLNQ, WA8WZX, WANTG, W5SYT, N7FTM, KA9CAP. 


>>> COM I/O ARCHITECTURE 
Continuing from Volumes 7,8, and 10, there are only three more registers 
to cover. 


Line Control Register (LCR) at address (BASE+3) 

This register allows you to configure the format of the serial data leav- 
ing the UART and (simultaneously) the format expected by the UART. All 
bits of this register are read/write. 


Bit 0&1: These two bits select how many data bits are transferred in each 
asynchronous character. 5,6,7, or 8 bits are selected with values 
of 00,01,10, or 11 respectively. For example, if you desire 7 data 
bits, set BitO to O and Biti to 1. 


Bit 2: Set to @ if you want one stop bit generated on outbound data and 
checked on inbound data. Setting to 1 chooses 1-1/2 stop bits with 
5-bit data and two stop bits with 6,7, or 8-bit data. 


Bit 3: Set to 1 to generate a parity bit. Set to 0 if you want no parity 
bit at all. If this is set to 0, the next bit has no effect. 


Bit 4: Even Parity Select. When Bit3 is 1 and Bit4 is 0, an odd number of 
1's is transmitted or checked in the data bits and parity bit. 
When Bit3 is a 1 and Bit4 is a 1, an even number of bits is trans- 
mitted or checked. 


Bit 5: When set to 1, the function of Bit4 is reversed. 


Bit 6: Set Break. When this bit is set to 1, the serial output is forced 
to the spacing state (same as data=0) and remains until changing 
this bit to a 0. 


Bit 7: This is the Baud-Rate Divisor Latch Access Bit. This bit is set to 
@ for normal operation allowing access of the transmitter and re- 
ceiver buffers at BASE+0, and the Interrupt Enable Register at 
BASE+1. When set to 1, these same addresses access the Baud Rate 
Divisor. 


Line Status Register (LSR) at address (BASE+5) 


This register provides information about recent data transfer. All bits 
are not read/write. 


Bit 0: 


Bit 1: 


Bit 2: 


Bit 3: 


Bit 4: 


Bit 5: 


Bit 6: 


Bit 7: 


Data Ready. The UART sets this bit to 1 whenever a complete incom- 
ing character is available in the receiver buffer. It is reset to 
@ by writing a zero or by reading the receiver buffer. Bit1 
through Bit4 are "errors" that produce a RLS interrupt (see IER 
and IIR descriptions). 


Overrun. This bit is set to 1 whenever the receiver buffer was not 
read by the CPU before the next character was transferred into the 
receiver buffer (overwriting the lost character). This bit is re- 
set to 0 whenever the CPU reads the LSR. 


Parity Error. If this bit is 1, the received character did not have 
the correct even or odd parity as selected by the bits in the LCR. 
It resets to 0 whenever the CPU reads the LSR. 


Framing Error. This bit is set to 1 whenever the stop bit following 
the last data bit (or parity, if selected) is detected in the spac- 
ing level. (A stop bit is suppose to be mark status.) 


Break Received. This is set to 1 whenever the received data input 
is held in spacing status longer than a full word's time: the total 
of start bit, data bits, parity, and stop bits. 


Transmitter register empty. This bit is 1 when the UART is ready 
to accept a new character for transmission. It actually switches 
to 1 when the previous character is moved from the transmitter 
holding register to the transmit shift register. It becomes 0 con- 
currently with the loading of the holding register by the CPU. 


Transmitter shift register empty. This bit is 1 whenever the shift 
register is idle (nothing being transmitted). It becomes 0 when 
the shift register gets a character from the transmitter holding 
register. 


Permanently 0 


Baud Rate Divisor Latch at addresses (BASE, BASE+1) 


These two registers set the bits per second rate transmitted by the UART. 
This is a 16-bit divisor for the clock fed into pin 16 of the 8250 UART, 
giving a frequency xsixteenx times the desired baud rate. Pin 16 is usu- 
ally fed with a frequency of 1.8432 MHz. 


The LSB (least significant byte) is written to (or read from) address 


BASE, and the MSB (most significant byte) is written/read from address 
BASE+1. This is true only when the Divisor Access Bit in the LCR is set 
to 1. 


The following table can be used if a 1.8432 Mhz clock is used (table 
values are decimal): 


300 1200 2400 4800 9600 19200 
MSB 1 0 0 0 0 0 
LSB 128 96 48 24 12 6 


Lastly, a request: Please look in any data book you have and try to iden- 
tify the following three chips. Two of each are surface mounted on the 
bottom side of the ZL power supply switching regulator board. I need to 
find out how they're suppose to work to know if mine are working! A pin- 
out and short description would be GREATLY appreciated! 


73, Brian Mork (Opus-OVH) KAOSNF@wb7nn£.d#spokn.wa.usa 
Internet ka9snf@opus-ovh.spk.wa.us 
6006-B Eaker, Fairchild, WA 99011 


Brian Mork Internet bmork@opus-ovh.spk.wa.us 
Amateur Radio ka9snf@wb7nnf.#spokn.wa.usa 
USMail 6006-B Eaker, Fairchild, WA 99011 


Date: Mon, 31 May 1993 13:27:47 GMT 

From: usc!cs.utexas.edu! swrinde! gatech!wa4dmei! ke4zv! gary@network.UCSD.EDU 
Subject: Need a data radio recommendation. (9600 min, 56K ??) 

To: packet-radio@ucsd.edu 


In article <1993May28.134933.24972@hp1.holl.com> dave@hp1.holl.com (David Vrona) 
writes: 

> 

>On a related note, what kind of equipment is required to go 56Kbaud??? This 
>is where I would like to be someday! 


Well, at 56kb the GRAPES modem xisx the radio, it's an RF modem, so all 
you need is a transverter to kick it's 29 MHz input/output up to the 
UHF band of your choice. The now out of production Microwave Modules 
MMT432S is commonly used, but any transverter with similar specs will 
do nicely. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


| gatech!wa4mei!ke4zv! gary 
| uunet!rsiatl!ke4zv! gary 
| emory!kd4nc! ke4zv! gary 

| 


Date: 31 May 1993 22:22:51 GMT 

From: olivea!charnel! kirk@uunet.uu.net 
Subject: NOS 

To: packet-radio@ucsd.edu 


am looking for the NOS Net Cordinaor, the closed one to 
Chico California, If you know who he is, please mail me his 
internet Address, Thanks. 


Date: 31 May 93 23:13:15 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Packet Radio 

To: packet-radio@ucsd.edu 


help 


Date: 31 May 93 11:42:53 GMT 

From: usc!math.ohio-state.edu!uwm.edu!biosci! parc! barrnet.net!noc.usfca.edu! 
noc.usfca.edu!callis@network.UCSD.EDU 

Subject: PBBS setup for Unix... 

To: packet-radio@ucsd.edu 


This is for all of you packet wizards/programmer types out there... I am 
running a Unix based machine with a direct connect to the Internet via 
our host here at USF. I am running under linux locally, which is 
connected via ethernet to the rest of our network. I thought it would be 
great if I could get a TNC to act just like my dialups and allow logins 
via packet radio. The fact is, I don't have a clue as to how to do 
this... Basically, what I want, is that when someone connects to my TNC, 
they get a login prompt from Linux. From there, they log in and do all 
the stuff one does under Unix, with the added benefit of true internet 
connection. If anyone has an idea how to do this, please e-mail me at 
the address below. 


Thanks, 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


*x Kim C. Callis * 
*x Univ. of San Francisco, San Francisco, CA * 
*x EMAIL: callis@usfca.edu or callis@dons.ac.usfca.edu * 


KAKA IKK KKK KIKI IKK IKI III IKI III KIKI III III KIKI III KIKI IIIA III IKI IK 
DISCLAIMER: As long as nothing I say attempts to represent the 

views of the Univ. of San Francisco, they could care less what I 
have to say. Meaning that anything said, like it or not, is strictly 
my own personal opinion and views. 


Date: Mon, 31 May 1993 07:42:39 MST 

From: usc!math.ohio-state.edu!cyber1.cyberstore.ca!van-bc!vanbc.wimsey.com! 
cs.ubc.ca!unixg.ubc.ca! kakwa.ucs.ualberta.ca!ersys! ve6mgs!rec-radio- 
info@network.UCSD.EDU 

Subject: Welcome to rec.radio.info! 

To: packet-radio@ucsd.edu 


Archive-name: radio/rec-radio-info/welcome 
Last-modified: $Date: 1993/05/16 21:57 $ 
Version: $Revision: 1.05 $ 


xxk Welcome to rec.radio.info! «xx 


Welcome to rec.radio.info, a group that aims to provide a noise-free source 
of information and news for the entire rec.radio hierarchy. 


Two introductory articles about rec.radio.info are posted to the group and 

to news.answers every two weeks. You are now reading the first article, which 
explains what rec.radio.info is, and answers some Frequently Asked Questions. 
The second article is titled "Submission Guidelines", and you only need to 
read it if you want to submit an article to rec.radio.info. 


You can skip to the next section of this article by searching for the next 
" -- " string. The sections available are: 
- What is the purpose of rec.radio.info? 
- Why are messages almost always cross posted to rec.radio.info? 
- What is a 'follow-up', and what does 'moderated' mean? 
- OK, so now I know what 'moderated' means. Tell me more. 
- What type of material is considered inappropriate? 
- I do not have access to news, how can I get the information posted to 
rec.radio.info? 
- Will the material appearing in rec.radio.info be archived somewhere? 
- I have a regular posting with timely information, is there a way to 
speed up it's delivery, or automate for more convenience? 


-- What is the purpose of rec.radio.info? 


The purpose or charter of rec.radio.info is to provide the Usenet community with 
a resource for information, news, and facts about any and all things radio. 


All the other rec.radio groups are intended for discussions and general chit 
chat about radio. Rec.radio.info will contain informational, factual articles 
only. Follow-ups are redirected to an appropriate other group, and further 
discussion (if any) will not take place in rec.radio.info. 


In order to ensure that rec.radio.info contains only appropriate articles, it 
was decided to create the group as a moderated newsgroup. 


-- Why are messages almost always cross posted to rec.radio.info? 


It provides a "tag" for each article to be assembled into a filtered 
presentation in rec.radio.info (even with cross-posting, only one message, with 
a unique Message-ID, is propogated across the net). This tag also facilitates 
a pre-existing method of dropping or cancelling the articles locally within the 
discussion groups if you don't want to see them. This accommodates individuals 
who want to separate the bulletins from the discussions, discussions from the 
bulletins, as well as those who are adamant about not reading another 

newsgroup and wanted to see everything all in one basket. 


With the total size of Usenet (in number of newsgroups and total traffic) 
doubling every year or so, this is no insignificant contribution to reducing 
information noise and chaos. Making the discussion groups a catch-all, and 
making extra newsgroups filters on that catch-all, is also the most realistic 
way to implement such a scheme (It's not intuitively obvious what the charter, 
contents, and general appropriate topics for each and every newsgroup are. 
Seeing FAQ's and charter/intro postings in the home newsgroup is beneficial 
for new readers). 


By cross-posting one only is adding a few tens of bytes to each bulletin (to 
specify the extra group on the Newsgroups line), but are adding the capability 
for very powerful filtering features available on most news servers, 
listservers and readers. Your local news guru could probably explain these 
features in more detail. 


In rn, for example, according to Leanne Phillips in her rn kill-file FAQ, add 
a line of the form: 

/Newsgroups:.*[ ,]rec\.radio\.info/h:j 
either in ~/News/KILL (if you don't want to see rec.radio.info articles 
anywhere) or ~/News/rec/radio/amateur/misc/KILL (if you don't want to see them 
just in rec.radio.amateur.misc). The latter method means your kill file will 
only be consulted during rec.radio.amateur.misc (and hence runs more 
efficiently), and will probably work for most people. 


In nn, according to Bill Wohler in his nn FAQ, add a line of the form: 
rec.radio.info:!s/:% 
in ~/.nn/kill (if you don't want to see rec.radio.info articles anywhere), or 
put the following lines: 
sequence 
rec.radio.info 
rec.radio. 
at the end of ~/.nn/init in order to see all the rec.radio.info bulletins first, 
then read the remaining rec.radio.* without the bulletins. 


-- What is a 'follow-up', and what does 'moderated' mean? 


If you are new to Usenet and are not familiar with the terminology, you might 
want to read the general introductory articles found in the newsgroup 
news.announce.newusers. Doing so will make your life on the net much easier, 
and will probably save you from making silly beginner's mistakes. 


If you think that at this moment you are reading an echo, a conference, or 
a bulletin board, I'd also strongly suggest a trip over to 
news.announce.newusers. 


For the rest of this article, I will assume you have a basic knowledge of 
Usenet terminology and mechanics. 


A moderated group means that any article that needs to be posted to the group 
has to be accepted by the moderator of the group. Since we need to ensure that 
followups to an article (discussion) do not show up in the rec.radio.info 
newsgroup, the ‘Followup-To:' header line contains a newsgroup that is 
appropriate for disussions about the specific article. 


-- OK, so now I know what 'moderated' means. Tell me more. 


Rec.radio.info is a moderated newsgroup, which means that all articles 
submitted to the group will have to be approved by the moderator first. 


The current moderator of the group is Mark Salyzyn. Submissions to 
rec.radio.info can be posted, or e-mailed to: 


rec-radio-info@ve6émgs.ampr.ab.ca 
Comments, criticisms, suggestions or questions about the group can be e-mailed 
to: 


rec-radio-request@ve6mgs.ampr.ab.ca 


But before you do so, please be sure to check out the "Submission Guidelines" 
article. 


The influence of the moderator should be minimal and of an administrative 


nature, consisting chiefly of weeding out obviously inappropriate articles, 
while making sure correct headers etc. are used for the appropriate ones. 


-- What type of material is considered inappropriate? 


There are three broad categories of articles which will be rejected by the 
moderator: 


1) Requests for information: rec.radio.info is strictly a one-way street. I 
receive information in my mailbox; I then post it to rec.radio.info. 


Requests for specific information belong in the normal discussion newsgroups. 


If your request gets answered, you might consider passing the answer on to 
rec.radio.info, though. Especially if you can edit it into a informational, 
rather than a discussion, format. 


2) Obvious discussion articles, or articles that appear unsubstantiated. 


3) Commercial stuff: a relatively unbiased test of a radio product would be 


accepted, but any hint of for-profit might be reason for rejection. For three 


reasons: This is not the purpose of the list, for-profit is a controversial 
topic, and this list may be passed onto Amateur Packet Radio (where 
for-profit is prohibited except under certain provisos). 


rec.radio.swap (or possibly comp.newprod) may be more deserving of the 
posting in any matter. 


Similarly, copyrighted material generally cannot be used. If it's TRULY 
worthwhile to the net, I would recommend obtaining permission from the 
copyright holder. Please note the source, and if permission was given. I 
reserve the right to make the final decision concerning appropriateness in 
all situations. In most cases, a brief summary of, or pointer to, the 
copyrighted information may be all I can allow. 


-- I do not have access to news, how can I get the information posted to 
rec.radio. info? 


brian@UCSD.EDU (Brian Kantor) has kindly supplied a mail list server for 
rec.radio.info. Non of the articles will be digested, due to their size, so 


you will receive individual mailings for every article posted to the group. 


Mail sent to radio-info@ucsd.edu will be forwarded to the moderator and 
thus is an alias to rec-radio-info@ve6émgs.ampr.ab.ca 


To subscribe and unsubscribe via the listserver; the format for that is 


sub address radio-info 
unsub address radio-info 


where ‘address’ is your full mailing address. Send this request to 
listserv@ucsd.edu 


Note that the server will automatically delete any address that bounces mail. 
If you leave the address portion blank, it will try to deduce your address 
from the mail headers. This may not work if you are on bitnet, milnet or 
some other non-Unix host, so it is recommended to put your return address 

in any case. For example: 


sub mymailbox@myhost.mydomain.mil radio-info 
or 
sub MEMEMEO1@DMBHST.bitnet radio-info 


or something like that. 
-- Will the material appearing in rec.radio.info be archived somewhere? 


Yes. Still firming up details at the moment but here is a preliminary list: 
- unbc.edu as maintained by Lyndon Nerenberg <lyndon@unbc.edu> 
- nic.funet.fi maintained by Risto Kotalampi <rko@cs.tut.£1i> 
saved to /pub/dx/text/rec.radio.info currently stored as 
numbered files. 


Effectively this means that anything you post to rec.radio.info will be 
permanently stored, so your work will not be lost. 


-- I have a regular posting with timely information, is there a way to 
speed up it's delivery, or automate for more convenience? 


Yes, there is! It may take a bit of chatter with the moderator, but we are 
willing to take responsible people and provide them the means of posting the 
articles directly from their site. We will try everything we can as we fully 
realize that DX (distant signal) and astronomical data can be somewhat 
transitory. We are also willing to allow regular posters of information the 
same courtesy, even if the information is not as time critical. 


We refer to this as self-moderation, which is partly based on the model for 
news.answer. This requires co-operation and good will to be beneficial to 
the community in the rec.radio hierarchy. 


I suggest reading the posting guidelines for more information. I am open to 
suggestions. 


I thank the following individuals for their input into this article: 
rec.music.info moderator Leo Breebaart rec-music-info@cp.tn.tudelft.nl 
rec.radio.broadcasting moderator Bill Pfeiffer wdp@gagme.chi.il.us 
Paul W. Schleck, KD3FU pschleck@unomaha.edu 


Ian Kluft, KD6EUI ikluft@uts.amdahl.com 


Mark Salyzyn -- Moderator rec.radio.info 

Submissions to: rec-radio-info@veémgs.ampr.ab.ca 

Administrivia to: rec-radio-request@ve6mgs.ampr.ab.ca 

* Requests for information do xnot* belong in rec.radio.info x 


End of Packet-Radio Digest V93 #152 
KK KKK KKK KK KAKA KAKI IKKE K KR 


